Skip to content

feat(host-cli): add the previewnet network preset - #440

Open
peetzweg wants to merge 1 commit into
mainfrom
feat/previewnet-preset
Open

feat(host-cli): add the previewnet network preset#440
peetzweg wants to merge 1 commit into
mainfrom
feat/previewnet-preset

Conversation

@peetzweg

Copy link
Copy Markdown
Member

What

--network previewnet, a second preset beside paseo-next-v2, with previewnet's People, Bulletin and Asset Hub endpoints, their genesis hashes, and the identity backend on its staging environment.

Why

previewnet is where products whose runtime descriptors target it do their on-chain testing, and it is already a first-class network id in this repo: the playground e2e defaults to VITE_NETWORKS=paseo-next-v2,previewnet (playground/playwright.config.ts:32, playground/tests/e2e/dotli-diagnosis.ts:35). The CLI was the one host that could not reach it.

Without the preset, such a product runs split: its statements and host chain routes land on nextv2 while its own chain reads go to previewnet. That is consistent enough for two local players, but it rules out testing a CLI host against a phone, and it rules out statement-store interop with the network the product actually ships against. One preset closes both.

How

The crate was already built for several presets: Network::value_variants() drives every test and NetworkConfig names each role, so the preset itself is one enum variant, one config arm and one endpoint table.

The rest of the diff is the drift guards, which only covered the default preset:

  • the_spec_genesis_table_matches_the_preset and the_typescript_chain_constants_match_the_preset now loop over presets instead of reading Network::PaseoNextV2 directly, so a future preset cannot skip them. Both hand-maintained copies gained previewnet rows: SPEC.md §14.1, and PREVIEWNET_INDIVIDUALITY / PREVIEWNET_ASSET_HUB in well-known-chains.ts. Products sign CheckGenesis over the TypeScript constant, so a preset without one is only half added.
  • every_preset_is_a_test_network is now an explicit host allowlist rather than a paseo || testnet substring test. previewnet's hosts contain neither word, and the invariant this guard exists for is "no production network", which a substring cannot express. Worth a reviewer's eye, since it is the guard standing in front of the plaintext mnemonic store. Every entry is a disposable deployment, and the identity backend's own /api/v1/version reports "environment": "staging".
  • The live genesis test's role-name check now accepts both names the People role answers to. previewnet's People chain calls itself Individuality Local, and PASEO_NEXT_V2_INDIVIDUALITY already shows the two words are one role.

Named previewnet, not preview, to match the id the playground and dotli already use, so HostChainSet::network reads the same string a product sees elsewhere.

Verified live

the_advertised_genesis_matches_what_each_chain_reports is no longer single-preset. Run with --ignored it asks all six chains for their own genesis and name:

paseo-next-v2 People   89a63b11… matches wss://paseo-people-next-system-rpc.polkadot.io (Paseo People Next)
paseo-next-v2 Bulletin 8cfe6717… matches wss://paseo-bulletin-next-rpc.polkadot.io (Paseo Bulletin Next)
paseo-next-v2 AssetHub 23e730eb… matches wss://paseo-asset-hub-next-rpc.polkadot.io (Paseo Asset Hub Next)
previewnet    People   3138c6d4… matches wss://previewnet.substrate.dev/people (Individuality Local)
previewnet    Bulletin 2778b1c9… matches wss://previewnet.substrate.dev/bulletin (Bulletin Local)
previewnet    AssetHub 4d11c803… matches wss://previewnet.substrate.dev/asset-hub (Asset Hub Local)

Also ran the CLI on the new preset: state lands in <base-path>/previewnet/signing-host, so the two presets keep separate signer identities on one machine.

Local checks: cargo +nightly fmt --check, cargo +nightly clippy --workspace --all-targets --all-features -- -D warnings, and cargo test -p truapi-host-cli --bins (103 passed).

One thing I could not verify, and a question

Auto-provisioning a lite username on previewnet fails, because that identity backend wants a bearer token for write requests:

Error: attest account auto-1
Caused by:
    username registration failed (401 Unauthorized): Missing Authorization Header

Reads against it work (GET /api/v1/attester returns the same attester key as the nextv2 deployment, from the same build), and nothing outside the backend is affected, so a previewnet signer works today with --mnemonic for an account that already holds a username there. Both README and SPEC state this.

So: is there a token intended for headless use, or a different endpoint for it? If a token is the answer, sending it is roughly fifteen lines (a flag plus an env var, one header when set) and I am happy to add it here or in a follow-up. I left it out rather than ship a path I cannot exercise.

Merge order

This touches the same README paragraph as #439 and the same package as #438. Whichever lands first, I will rebase the others.

previewnet is where products with previewnet descriptors do their on-chain
testing, and it is already a first-class network id here: the playground e2e
defaults to `paseo-next-v2,previewnet`. The CLI was the one host that could not
reach it, so such a product ran split, with statements and host chain routes on
nextv2 while its own chain reads went to previewnet.

The preset itself is one variant and one config arm. The rest generalises the
drift guards, which only covered the default preset: the SPEC table and the
TypeScript constant tests now loop over presets, and both copies gained
previewnet rows. The test-network guard becomes an explicit host allowlist,
because previewnet's hosts contain neither `paseo` nor `testnet` and the
invariant it protects is "no production network". The live genesis test accepts
both names the People role answers to, since previewnet's chain calls itself
Individuality Local.

Auto-provisioning a username on previewnet needs a bearer token the CLI does not
send, so that path fails with 401 and is documented in the README and SPEC; a
previewnet signer works today with an account that already holds a username.
@peetzweg
peetzweg requested a review from a team August 18, 2026 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant